The VPRO Digital Guide 1994/vpro.iso/software/mac/packed/sparkle2.hqx/(Docs)/New in 2.12

Text File | 1994-07-28 | 19.5 KB | 321 lines

What's new in 2.1.2?
Ñ╩In 2.1 when a window was first opened and the Video menu selected, the
    menu showed Palindrome looping as on even though it was not. This is fixed.
Ñ In 2.1 I had a serious (crashing) possible bug that could occur when a
    window was closed. This was because the life cycles of video encoding
    threads and video playing threads are different. I must rationalize
    these to one model, but till then I've applied a quick and dirty fix.
Ñ Long complicated pathways through about six auxiliary functions, used when
    threads died and a holdover from the Sparkle 1.x days, have been removed to
    use a much simpler virtual function based scheme. This is slightly faster
    and, more important, much simpler hence, hopefully, less buggy.
Ñ╩Deactivating/activating of the ``Change file type to MPEG'' radio button in
    the open file dialog was a little erratic. This has been fixed.
Ñ╩Rudimentary balloon help has been added.
Ñ╩When memory is very low and a window starts being opened, but fails
      partway, the cleanup code was slightly wrong. Now fixed.
Ñ╩Improved the display on 4-bit color screens. It was very blocky.
Ñ╩Changed the progressbar to display properly on 4-bit color screens.
    The two colors used for foreground and background were being mapped onto
    the same color.
Ñ╩Change the progress bar to update itself better when parts of the window are
    uncovered. Before parts would be drawn quite a while before other parts
    giving a result that looked silly.
Ñ Added a menu option to allow operation without ever yielding time to
    WaitNextEvent. If you don't need to give time to background applications,
    use this option for faster, less jerky, playback.
Ñ Speech manager code used to announce a delay when encoding an MPEG
    could, if timing was just wrong, crash. I think the problem was that the
    Speech Manager was building internal data structures on the stack, and
    that stack disappeared when the the MPEG encoding thread died. Anyway
    I've modified the speech code so this can't happen.
Ñ Discovered a serious problem in my video encoding code. When an MPEG
    window was resized while it was being converted to another MPEG or QT
    movie, the result could be a munged image for a few frames. The fix
    involved a major structural readjustment of Sparkle---ALL video
    manipulations now pass through ThreadEvent queues---but the result is
    that for the first time I feel confident about the theoretical
    underpinnings of Sparkle---that while minor bugs may remain, there are
    no conceptual nasties waiting to bite me.
Ñ╩When windows are resized, the resizing is done in a manner that leaves
    no gunk in the window in the moments before the resizing is complete.
Ñ╩I discovered yet another way in which things could crash---The MacOS call
    DrawPicture() will crash if it runs out of memory---thanks Apple.
    There's nothing I can do about this, so what I did do is try to trap
    situations that form a pattern of using DrawPicture() while memory is
    getting lower and warn you that memory is running low. This doesn't
    catch all situations but catches some.
Ñ The play/pause button no longer toggles between states when you start a
    movie saving or pause it. This is because what I was doing to get this
    to work in QT 1.x no longer works nicely in QT 2.0 --- flickering frames
    result. I guess this is a consequence of DataPipe or something.
    Anyway I've replaced this with indicators in the title bar.
Ñ I made a few changes to allow easier more sensible playback of QT movies that
    consist of only sound. This is at present rudimentary but is a start.

What's new in 2.1?
Ñ╩Yet again memory management has been fiddled with. Previous tinkering with
    memory management was to ensure that my own code never crashed for lack
    of memory. Building on top of that, I've tried to ensure that calls to
    the operating system won't crash for lack of memory. This is more
    difficult because, obviously, I don't know just what the memory
    requirements of each call are. However I've done the best I can, and
    the resultant code seems even more robust than 2.02.
Ñ╩The scheduling has been revamped based on the threading. I now make
    intelligent decisions about which thread to schedule when. Also calls to
    the main event loop, which were very expensive in time, have been cut
    dramatically. the result is about a 15% speed boost all round.
Ñ╩MPEG playback is now based on genuine timing, not on simply playing
    every frame as fast as possible. Like QuickTime movies, you can play
    MPEGs back in real time or play every frame. I also now support the
    movie controller variable speed controls obtained by control-clicking
    on the forward/backward stepper buttons.
Ñ╩You can now set QT and MPEG movies to loop.
Ñ╩You can now grow or shrink MPEG and QT movie windows.
Ñ╩The cursor is now hidden when movie playback starts, until you move it.
    This seems to be a reasonable compromise for preventing flickering cursor
    when starting a movie using the keyboard, but atill allows the user
    easily to find the cursor when needed.
Ñ╩When files are opened, windows are now tiled in a vaguely intelligent fashion,
    attempting both to use the available screens with best depth, and to
    avoid window overlap.
Ñ╩Dragging windows is now aligned to a grid of optimal window placement. This
    gives better movie playback.
Ñ Can now show/hide the progressPane, movie controller and frame count with the
    tab key using tab, shift-tab, control-tab.
Ñ╩The drawing of the progress bar has been altered slightly, to fix cosmetic
    defects and to make the appearance closer to that of the movie controller.
Ñ╩Support for MPEGs with a pixel aspect ratio not equal to one has been added.
      At present this isn't switched on because some dumb MPEGs out there
      have a bogus aspect ratio encoded in them. However if someone wants
      this feature right away, I'll add a user interface to access it.
Ñ╩Support for MPEGs with multiple sequence headers has been added, not
    that I have ever seen such an MPEG.
Ñ Playback is now much faster through a variety of mechanisms. However
    this has, as a consequence, lower quality playback. You may set through
    preferences which optimizations you're willing to accept for faster
    playback and which you're not willing to accept. All optimizations are
    turned off when converting an MPEG to another format so that you'll get
    the best possible quality.
    Playback speed is now about 1.6 times faster for 24 bit screens, about
    2.5 times as fast for 8 bit grey screens, and improvements in between for
    other screen depths.
Ñ Special purpose display code is used for
    24 bit, 16 bit and 8 bit color screens and 8 bit grey screens.
    All other screens are sent through one of the above special purpose codes
    then use QuickTime to convert the pictures to the appropriate screen depth.
    Obviously special purpose code is faster. If I get lots of calls for
    screen depths other than the one's I'v supported directly, I'll look into
    adding more special purpose code.
Ñ In 2.0 I broke the support for adding files called name.mpg, but without
    a file type of MPEG so you could open files of that type but nothing
    would happen. Sorry about that. It's been fixed.
Ñ When files are opened and are not of the default Mac types (for example
    files imported from a UNIX box, or files on a PC CD ROM) Sparkle uses
    more intelligence in deciding whether to open these files as MPEGs, QT
    movies or pictures. If this mechanism is still not general enough for
    some users (I image mainly users sharing data with PCs), let me know.
Ñ╩The ``official'' MPEG encoding pattern of IBBPBBPBBPBB is now a pre-defined
    option. Some people asking for this as a pre-defined option have given me
    slightly different patterns as the ``official'' pattern. However what I
    have used is, to the best of my knowledge correct, and I'm assuming these
    people who wrote to me simply made typos. If you have comments on this,
    please mail me.
Ñ I twiddled the RGB to YCrCB conversion code that is the first step in
     encoding MPEGs. The changes won't affect anyone except people creating
     MPEG movies whose width or height is odd, in which case the very last
     row or column of pixels will have more accurate color. The important
     change, however, was that I no longer read beyond the end of some arrays,
     so I'm ready for when Apple give us protected memory a year from now.
Ñ Under certain rare circumstances, depending on the number of frames int the
    input file and the IPB pattern used, the last frame or two of the input
    would not be saved in the output MPEG. This is fixed.
Ñ MPEG encoding now can specify a frame rate (in the past this was always
    30 fps). Sure the range of choices is limited---blame the people who
    wrote the MPEG spec---those are, basically, the only choices.
    1) Can people with MPEG hardware verify that this works for me?
        On my mac with 10fps max playback, it's tough to see if this works.
    2) There are some frame rates I've omitted that are very close to those
       I give, for example 29.97 fps. At some point i'll get the finicky
       time right to support these but it's a pretty low priority compared
       to sound.

What's new in 2.01?
Ñ╩Implemented padding YUV macroblocks with a repeat of the last value of
     each YUV triplet when macroblocks at the edge of a frame spill over
     the edge. The most common case of this is a 120 pixel high movie with a
     macroblock height of 128. In the past this spillover was filled randomly.
     The result of this is that MPEGs created are about 15% smaller.
Ñ╩Some diddling with the code used by the IDCT algorithm gives a speed boost
    of about 5% to both playing and encoding MPEGs.
Ñ Fixed a serious bug that prevented you from playing an MPEG if you started
    playing    it then interrupted it. A nice byproduct of this is that I got
    jogging of MPEGs fully operational. You can now repeatedly view a section
    of the MPEG by hitting command-right-arrow then command-left-arrow to keep
    the MPEG moving forwards then backwards.
Ñ╩Altered the alert popped up when the Thread Manager is not present to make
    it more palatable to corporate and institutional users.
Ñ╩Fixed the MPEG buffering which would give problematic results for very small
    MPEGs (say three frames or less).
Ñ╩Finally went through all resources, marking them purgable or not and removing
    the unnecessary ones.
Ñ╩Fixed the "PBBIBB" default frame set to make it correspond to the user view
    of things, not my programmer's view.
Ñ Fixed a bug that prevented a temporary movie created by the movie controller
    handling an MPEG file from being destroyed.
Ñ╩Fixed two bugs in the Think Class Library dealing with the loading of dialogs
    then manipulating them without setting their memory blocks to non-purgable.
Ñ╩Fixed a long-standing bug in the MPEG player buffer-handling code that
    would cause the MPEG frame index to be incorrect if it was created while
    memory was short. This probably never caused problems except for very long
    MPEGs.
Ñ╩When converting a QT movie into a different movie form, the dialog that comes
    up asking you for compression options will have the frame rate and key
    frame rate set at what the original movie used, sparing you from having to
    guess. I will eventually have this working across all file conversions,
    not just movie-->movie.
Ñ The Think C 6 compiler contains a bug when performing code-motion optimization
    on complex loops. If you run through the assembly it produces in this case,
    it performs some very nifty register coloring and creating induction
    variables for the loop. It then leaves out one crucial instruction to
    update one of the induction variables each pass through the loop and so
    the code is garbage.
    As far as I can tell, this only affects one function in my code and I have
    used a #pragma there to prevent it happening, but the fact that bugs like
    this exist in the compiler is a little worrying.
Ñ╩Revised all memory allocation so that it is more likely to not to use up all
    memory reserves and leave nothing for toolbox.
Ñ Found an especially nasty bug involving grabbing frames from a QT movie
    which, when memory ran low, would leave the system GrafPort/GDevice
    environment in an inconsistent state.
Ñ╩Revised all uses of GWorld to use tempMem, but fallback to local heap if
    tempMem is unavailable.
Ñ╩Altered the strings used to popup error messages at startup if QuickTime
    is not available. These got mixed up when I moved code around.
Ñ╩The code to build the MPEG index when an MPEG is opened would run out of space
    when a very large MPEG was opened---one of a thousand frames or more. Now
    memory is allocated for this a little more flexibly.
Ñ╩Fixed a bug I inserted when I changed from Sparkle 1.6 to 1.7. I rewrote the
    Berkeley motion vector code to speed it up and in the process made one
    little typo, shifting a variable right by 1 not 2. The effect of this, in
    Sparkles 1.7 and 2.0 was that, under very rare occasions, blocks of color
    would appear a few pixels off from where they should be. The only place I
    ever saw this was three or four frames of the MPEG sales110.mpg.
    This is not related to a separate problem.
    The motion estimation code in the MPEG encoder (at present the Berkeley code
    with practially no changes) is not perfect. It sometimes creates
    blocks that appear to be wildly off from where they should be (by quite a few
    pixels). This is not very obvious in real life, but is very obvious in animation.
    This is largely a quantization artifact---it goes away if you lower the
    quantizations. But obviosly you don't want to do that always, just where
    necessary, so you really want a smarter quantizer that is adaptive.
    I'll work on issues like this as soon as I can.
Ñ When converting a movie with sound to MPEG or QT, occasionally pops of sound could
    be heard. This is fixed.
Ñ When converting movies with very low keyframe rates (say 20 or more dependent
    frames per keyframe) occasionally the display of the movie would get confused
    and appear to alternate between two different frames. This is fixed.

What's new in 2.0?
Ñ The structure of the code has been completely altered to be based on
    threads. This makes it much easier for me to add new features to the code
    while having it retain MultiFinder friendliness.
Ñ Now opens and plays QT movies.
Ñ Now can create MPEG files. General conversion from
     {QT or MPEG}--->{QT or MPEG} is possible.
Ñ Many minor changes to the way files are opened, named and such.
Ñ Makes minor use of the speech manager if installed.
Ñ You can now play MPEGs backwards.

What's new in 1.71?
Ñ The progress bar now updates itself properly at the very end of saving
    each frame to Quicktime. It also draws itself better on b/w screens.
Ñ More of the default QT movie player keystrokes now work.
Ñ The app notes if an MPEG file has many errors and if so warns you that
    it has probably been transferred to the mac incorrectly.
Ñ I have incorporated a workaround to make Sparkle work with the QT VM
    extension. However I do not recommend you use the two together. If you do
    use QT VM you will find Sparkle's memory usage a little less efficient
    than without using QT VM. This is because of the way QT VM works.
Ñ Fixed a bug that caused unusually sized MPEGs to display as distorted.
Ñ Sparkle should now cope a little better with low memory situations.
Ñ Added a small tweak to improve drawing on 16bit screens under low
    memory conditions.
Ñ Uses the most recently released version on the floating windoid.
Ñ I have learned of an app that will convert QT to MPEG on the mac. It's
    not the easiest thing to use and I recommend this only for people
    who really need this, not for people who just want to play around.
    See the README file for details.

What's new in 1.7?
Ñ Opening files is much faster.
Ñ Fixed the size of the checkboxes in the Open File dialog to the correct
    size for all those millions of people who use Chicago as their system
    font cause they have no sense of aesthetics. Oops.
Ñ Now when Sparkle changes the file-type of an file, the Finder will update
    the icon immediately, instead of forcing you to open and close the
    folder to see a new icon. Thanks to Jamie McCarthy for telling me how
    to do this.
Ñ Added an "About Sparkle" dialog box to quieten the constant stream of
    complaints about this.
Ñ Changed the way progress is reported. I think the new scheme feels
    rather more elegant. (If you have a fast machine and only use small
    MPEGs, you may not notice this change much.)
Ñ Adde random access. You can now use the step backward stepper, or
    simply click in movie controller where you want to go. All standard
    movie controller clicks and keystrokes are supported.
Ñ Restructured the internal code vastly. This is what took most of the
    time and while it doesn't directly help you users, it gives me
     a framework that's much easier to build on. For example it should be
     trivial to add Apple Event support when I get round to that.
Ñ Three or four minor bugs were squelched, mostly involving Sparkle crashing
     when it encountered MPEGs with invalid data in them.
Ñ Now quits gracefully when started on a 68000 mac like a Classic, rather
    than crashing. I'm sure    lots of people care about this.
Ñ Added better multi-tasking support. This takes two forms.
    One is that the length of the timeslices Sparkle uses before giving up
    the CPU are now absolute times.  Before they were numbers that worked
    well for my SE/30, but probably not optimally for slower or faster
    machines.
    The second is that you can now context switch out of Sparkle while it
    is doing slow QT conversions (especially converting to Compact Video).
    The way I have implemented this is not wonderful, but the best I can
    do given the present way the code is structured. The next version
    will use the Thread Manager and will do this rather better.
    This second form of timeslicing is done through the
    SetSequenceProgressProc() call which is new in QT1.6 and which is why
    I now require use of QT1.6. Also QT does not yield the CPU very often,
    and (as far as I know) there is no way to make it yield more often.
    So while your machine is no longer completely frozen as it does its
    conversion, it's still not too pleasant to use for typing. I can't do
    much about this---complain to Apple and tell them to change this part of
    QT, or better yet the whole OS.

What's new in 1.6?
Ñ I became tired of continually having to explain to people about mac
    file types, so I wrote a file filter function for the Open File dialog
    box which displays ALL files with a .mpg suffix. This should make use a
    lot easier for novices.
Ñ Fixed a bug that involved writing to NULL.
Ñ Fixed a bug that prevented IBP type MPEGs from rewinding when they
    reached the end and the play button was hit twice.

What's new in 1.5.2?
Ñ I was disposing of a handle twice (specifically I was disposing of a
    pixmap and then its colortable, not realizing that DisposPixMap took
    care of the colortable for me.) Thanks to Dan Sears for pointing this out.
    I never noticed a problem due to this bug, but it's probably good to
    have killed it.

Whats new in 1.5.1?
Ñ One part of my speed optimizing code was not being initialized properly.
    This caused a very specific type of MPEG file to show parts of its first
    frame as greenish blobs. Now fixed.
Ñ The code to detect errors in a corrupted MPEG file has been made even
    more robust. Substantially better recovery from such errors, by
    rebuilding the lost parts of a frame from the previous frame, has been
    introduced. Thanks to a wonderfully corrupt MPEG file I pulled off
    usenet with about 15 misc errors in it for pointing out new and
    ingenious ways to fail.
Ñ New icons, courtesy of Richard Lim in Britain. I hope you like them.
    You will have to rebuild the desktop to see them.